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Abstract 


This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see 
RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be 
manipulated through the IMAP protocol. 


This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever 
possible. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9208. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 


This document may contain material from IETF Documents or IETF Contributions published or 
made publicly available before November 10, 2008. The person(s) controlling the copyright in 
some of this material may not have granted the IETF Trust the right to allow modifications of 
such material outside the IETF Standards Process. Without obtaining an adequate license from 
the person(s) controlling the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may not be created outside the 
IETF Standards Process, except to format it for publication as an RFC or to translate it into 
languages other than English. 
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1. Introduction and Overview 


This document defines a couple of extensions to the Internet Message Access Protocol [RFC3501] 
[RFC9051] for querying and manipulating administrative limits on resource usage (quotas). This 
extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. 


The "QUOTA" capability denotes a server compliant with [RFC2087]. Some responses and response 
codes defined in this document are not present in such servers (see Section 10 for more details), 
and clients MUST NOT rely on their presence in the absence of any capability beginning with 
"QUOTA=". 


Any server compliant with this document MUST also return at least one capability starting with 
the "QUOTA=RES-" prefix, as described in Section 3.1. 


Any server compliant with this document that implements the SETQUOTA command (see Section 
4.1.3) MUST also return the "QUOTASET" capability. 
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This document also reserves all other capabilities starting with the "QUOTA=" prefix for future 
IETF Stream Standard Track, Informational, or Experimental extensions to this document. 


Quotas can be used to restrict clients for administrative reasons, but the QUOTA extension can 
also be used to indicate system limits and current usage levels to clients. 


Although the IMAP4 QUOTA extension specified in [RFC2087] has seen deployment in servers, it 
has seen little deployment in clients. Since the meaning of the resources was implementation 
dependent, it was impossible for a client implementation to determine which resources were 
supported, and it was impossible to determine which mailboxes were in a given quota root (see 
Section 3.2) without a priori knowledge of the implementation. 


2. Document Conventions 


In protocol examples, this document uses a prefix of "C: "to denote lines sent by the client to the 
server and "S: " for lines sent by the server to the client. Lines prefixed with "//" are comments 
explaining the previous protocol line. These prefixes and comments are not part of the protocol. 
Lines without any of these prefixes are continuations of the previous line, and no line break is 
present in the protocol before such lines unless specifically mentioned. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Other capitalized words are IMAP keywords [RFC3501] [RFC9051] or keywords from this 
document. 


3. Terms 


3.1. Resource 


A resource has a name, a formal definition. 


3.1.1. Name 
The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. These MUST be registered with 
IANA. 


Supported resource names MUST be advertised as a capability by prepending the resource name 
with "QUOTA=RES-". A server compliant with this specification is not required to support all 
reported resource types on all quota roots. 

3.1.2. Definition 


The resource definition or document containing it, while not visible through the protocol, SHOULD 
be registered with IANA. 


Melnikov Standards Track Page 4 


RFC 9208 IMAP QUOTA March 2022 


The usage of a resource MUST be represented as a 63-bit unsigned integer. 0 indicates that the 
resource is exhausted. Usage integers don't necessarily represent proportional use, so clients 
MUST NOT compare an available resource between two separate quota roots on the same or 
different servers. 


Limits will be specified as, and MUST be represented as, an integer. 0 indicates that any usage is 
prohibited. 


Limits may be hard or soft; that is, an implementation MAY choose, or be configured, to disallow 
any command ifthe limit on a resource is or would be exceeded. 


All resources that the server handles MUST be advertised in a CAPABILITY response/response code 
consisting of the resource name prefixed by "QUOTA=RES-". 


The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX (Section 5.3), and 
ANNOTATION-STORAGE (Section 5.4) are defined in this document. 


3.2. Quota Root 


This document introduces the concept of a "quota root", as resource limits can apply across 
multiple IMAP mailboxes. 


Each mailbox has zero or more implementation-defined named "quota roots". Each quota root 
has zero or more resource limits (quotas). All mailboxes that share the same named quota root 
share the resource limits of the quota root. 


Quota root names need not be mailbox names, nor is there any relationship defined by this 
document between a quota root name anda mailbox name. A quota root name is an astring, as 
defined in IMAP4 [RFC3501] [RFC9051]. It SHOULD be treated as an opaque string by any clients. 


Quota roots are used since not all implementations may be able to calculate usage, or apply 
quotas, on arbitrary mailboxes or mailbox hierarchies. 


Not all resources may be limitable or calculable for all quota roots. Furthermore, not all resources 
may support all limits; some limits may be present in the underlying system. A server 
implementation of this memo SHOULD advise the client of such inherent limits, by generating 
QUOTA (Section 4.2.1) responses, and SHOULD advise the client of which resources are limitable 
for a particular quota root. ASETQUOTA (Section 4.1.3) command MAY also round a quota limit in 
an implementation-dependent way, if the granularity of the underlying system demands it. A 
client MUST be prepared for a SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. 


Implementation Notes: This means that, for example, under UNIX, a quota root may havea 
MESSAGE (Section 5.2) quota always set due to the number of inodes available on the filesystem; 
similarly, STORAGE (Section 5.1) may be rounded to the nearest block and limited by free 
filesystem space. 
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4. Definitions 


4.1. Commands 


The following commands exist for manipulation and querying quotas. 


4.1.1. GETQUOTA 


Arguments: quota root 

Responses: REQUIRED untagged responses: QUOTA 

Result: OK - getquota completed 
NO - getquota error: no such quota root, permission denied 
BAD - command unknown or arguments invalid 


The GETQUOTA command takes the name of a quota root and returns the quota root's resource 
usage and limits in an untagged QUOTA response. (Names of quota roots applicable toa 
particular mailbox can be discovered by issuing the GETQUOTAROOT command; see Section 
4.1.2.) Note that the server is not required to support any specific resource type (as advertised in 
the CAPABILITY response, i.e., all capability items with the "QUOTA=RES-" prefix) for any 
particular quota root. 


Example: 


S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 


eel 
C: G0001 GETQUOTA "!partition/sda4" 
: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 


S 
S: G0001 OK Getquota complete 


4.1.2. GETQUOTAROOT 


Arguments: mailbox name 
Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 


Result: OK - getquotaroot completed 
NO - getquotaroot error: permission denied 


BAD - command unknown or arguments invalid 
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The GETQUOTAROOT command takes a mailbox name and returns the list of quota roots for the 
mailbox in an untagged QUOTAROOT response. For each listed quota root, it also returns the 
quota root's resource usage and limits in an untagged QUOTA response. 


Note that the mailbox name parameter doesn't have to reference an existing mailbox. This can be 
handy in order to determine which quota root would apply to a mailbox when it gets created. 


Example: 


S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 
bassa 


[asa] 

C: G0002 GETQUOTAROOT INBOX 

: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 
: * QUOTA "#user/alice" (MESSAGE 42 1000) 

: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 


: G0002 OK Getquotaroot complete 


4.1.3. SETQUOTA 


Arguments: quota root list of resource limits 
Responses: untagged responses: QUOTA 


Result: OK - setquota completed 
NO - setquota error: can't set that data 
BAD - command unknown or arguments invalid 


Note that unlike other command/responses/response codes defined in this document, support for 
the SETQUOTA command requires the server to advertise the "QUOTASET" capability. 


The SETQUOTA command takes the name of a mailbox quota root and a list of resource limits. 
The resource limits for the named quota root are changed to the specified limits. Any previous 
resource limits for the named quota root are discarded, even resource limits not explicitly listed 
in the SETQUOTA command. (For example, if the quota root had both STORAGE and MESSAGE 
limits assigned to the quota root before the SETQUOTA is called and the SETQUOTA only includes 
the STORAGE limit, then the MESSAGE limit is removed from the quota root.) 


If the named quota root did not previously exist, an implementation may optionally create it and 
change the quota roots for any number of existing mailboxes in an implementation-defined 
manner. 
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If the implementation chooses to change the quota roots for some existing mailboxes, such 
changes SHOULD be announced with untagged QUOTA responses. 


Example: 
S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES- 
MESSAGE [...] 
[eel 
C: S000O GETQUOTA "#user/alice" 


: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) 


OTTA 


: $8000 OK Getquota completed 
C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 
S: * QUOTA "#user/alice" (STORAGE 58 512) 


// The server has rounded the STORAGE quota limit requested to 
the nearest 512 blocks of 1024 octets; otherwise, another client 
has performed a near-simultaneous SETQUOTA using a limit of 512. 


S: S0001 OK Rounded quota 
C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 


// The server has not changed the quota, since this is a 
filesystem limit, and it cannot be changed. The QUOTA 
response here is entirely optional. 


S: S0002 NO Cannot change system limit 


4.1.4. New STATUS attributes 


The DELETED and DELETED-STORAGE status data items allow for estimation of the amount of 
resources that could be freed by an EXPUNGE on a mailbox. 


The DELETED status data item requests the server to return the number of messages with the 
\Deleted flag set. The DELETED status data item is only required to be implemented when the 
server advertises the "QUOTA=RES-MESSAGE" capability. 


The DELETED-STORAGE status data item requests the server to return the amount of storage 
space that can be reclaimed by performing EXPUNGE on the mailbox. The server SHOULD return 
the exact value; however, it is recognized that the server may have to do a non-trivial amount of 
work to calculate it. If the calculation of the exact value would take a long time, the server MAY 
instead return the sum of the RFC822.SIZE of the messages with the \Deleted flag set. The 
DELETED-STORAGE status data item is only required to be implemented when the server 
advertises the "QUOTA=RES-STORAGE" capability. 
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Example: 
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES- 
MESSAGE [...] 
laas] 
C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) 
S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) 


// 12 messages, 4 of which would be deleted when an EXPUNGE 
happens. 


S: S0003 OK Status complete. 


4.2. Responses 


The following responses may be sent by the server. 


4.2.1. QUOTA 
Data: quota root name 


list of resource names, usages, and limits 


This response occurs as a result of a GETQUOTA, GETQUOTAROOT, or SETQUOTA command. The 
first string is the name of the quota root for which this quota applies. 


The name is followed by an S-expression format list of the resource usage and limits of the quota 
root. The list contains zero or more triplets. Each triplet contains a resource name, the current 
usage of the resource, and the resource limit. 


Resources not named in the list are not limited in the quota root. Thus, an empty list means there 
are no administrative resource limits in the quota root. 


Example: 
S: * QUOTA "" (STORAGE 10 512) 


4.2.2. QUOTAROOT 
Data: mailbox name 


zero or more quota root names 


This response occurs as a result of aGETQUOTAROOT command. The first string is the mailbox 
and the remaining strings are the names of the quota roots for the mailbox. 


Examples: 
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S: * QUOTAROOT INBOX "" 


// The INBOX mailbox is covered by a single quota root with 
name "". 


S: * QUOTAROOT comp.mail.mime 


// The comp.mail.mime mailbox has no quota root associated 
with it, but one can be created. 


4.3. Response Codes 


4.3.1. OVERQUOTA 


The OVERQUOTA response code SHOULD be returned in the tagged NO response to an APPEND/ 
COPY/MOVE when the addition of the message(s) puts the target mailbox over any one of its 
quota limits. 


Example 1: 


: A@@3 APPEND saved-messages (\Seen) {326} 

: + Ready for literal data 

: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 

From: Fred Foobar <foobar@Blurdybloop.example> 

: Subject: afternoon meeting 

: To: mooch@owatagu.siam.edu.example 

: Message-Id: <B27397-0100000@Blurdybloop.example> 
: MIME-Version: 1.0 

: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 


: Hello Joe, do you think we can meet at 3:30 tomorrow? 


D2: @ Gs GiG: Gas Go: OOD O 


: A@@3 NO [OVERQUOTA] APPEND Failed 


The OVERQUOTA response code MAY also be returned in an untagged NO response in the 
authenticated or the selected state when a mailbox exceeds soft quota. For example, such 
OVERQUOTA response codes might be sent as a result of an external event (e.g., Local Mail 
Transfer Protocol (LMTP) [RFC2033] delivery or COPY/MOVE/APPEND in another IMAP 
connection) that causes the currently selected mailbox to exceed soft quota. Note that such an 
OVERQUOTA response code might be ambiguous because it might relate to the target mailbox (as 
specified in COPY/MOVE/APPEND) or to the currently selected mailbox. (The EXTRA WG chose not 
to address this deficiency due to syntactic limitations of IMAP response codes and because such 
events are likely to be rare.) This form of the OVERQUOTA response codes MUST NOT be returned 
if there is no mailbox selected and no command in progress that adds a message to a mailbox 
(e.g., APPEND). 


Example 2: 
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: A@@3 APPEND saved-messages (\Seen) {326} 

: + Ready for literal data 

: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 

From: Fred Foobar <foobar@Blurdybloop.example> 

: Subject: afternoon meeting 

: To: mooch@owatagu.siam.edu.example 

: Message-Id: <B27397-0100000@Blurdybloop.example> 
: MIME-Version: 1.0 

: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 


: Hello Joe, do you think we can meet at 3:30 tomorrow? 


: * NO [OVERQUOTA] Soft quota has been exceeded 
: A003 OK [APPENDUID 38505 3955] APPEND completed 


DALY O' OG: OOOO OO ON @ 


Example 3: 


C: A004 COPY 2:4 MEETING 

S: * NO [OVERQUOTA] Soft quota has been exceeded 

S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY 
command completed 


5. Resource Type Definitions 


The following resource types are defined in this memo. A server supporting a resource type MUST 
advertise this as a CAPABILITY with a name consisting of the resource name prefixed by 
"QUOTA=RES-". A server MAY support multiple resource types and MUST advertise all resource 
types it supports. 


5.1. STORAGE 


"STORAGE" is the physical space estimate, in units of 1024 octets, of the mailboxes governed by 
the quota root. This MAY not be the same as the sum of the RFC822.SIZE of the messages. Some 
implementations MAY include metadata sizes for the messages and mailboxes, and other 
implementations MAY store messages in sucha way that the physical space used is smaller, for 
example, due to use of compression. Additional messages might not increase the usage. Clients 
MUST NOT use the usage figure for anything other than informational purposes; for example, they 
MUST NOT refuse to APPEND a message if the limit less the usage is smaller than the RFC822.SIZE 
divided by 1024 octets of the message, but it MAY warn about such condition. 


The usage figure may change as a result of performing actions not associated with adding new 
messages to the mailbox, such as SEARCH, since this may increase the amount of metadata 
included in the calculations. 


When the server supports this resource type, it MUST also support the DELETED-STORAGE status 
data item. 
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Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES- 
STORAGE" capability. 


A resource named the same was also given as an example in [RFC2087]. This document provides a 
more precise definition. 


5.2. MESSAGE 


"MESSAGE" is the number of messages stored within the mailboxes governed by the quota root. 
This MUST be an exact number; however, clients MUST NOT assume that a change in the usage 
indicates a change in the number of messages available, since the quota root may include 
mailboxes the client has no access to. 


When the server supports this resource type, it MUST also support the DELETED status data item. 


Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES- 
MESSAGE" capability. 


A resource named the same was also given as an example in [RFC2087]. This document provides a 
more precise definition. 


5.3. MAILBOX 


"MAILBOX" is the number of mailboxes governed by the quota root. This MUST be an exact 
number; however, clients MUST NOT assume that a change in the usage indicates a change in the 
number of mailboxes, since the quota root may include mailboxes the client has no access to. 


Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES- 
MAILBOX" capability. 


5.4. ANNOTATION-STORAGE 


"ANNOTATION-STORAGE' is the maximum size of all annotations [RFC5257], in units of 1024 
octets, associated with all messages in the mailboxes governed by the quota root. 


Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES- 
ANNOTATION-STORAGE" capability. 


6. Interaction with IMAP ACL Extension (RFC 4314) 


This section lists [RFC4314] rights required to execute quota-related commands when both RFC 
4314 and this document are implemented. 


Operations\Rights 1 r s w i c x t e a Any Non 
GETQUOTA + 


GETQUOTAROOT s . 
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Operations\Rights 1 r s w i c x t e a Any Non 


SETQUOTA + 
Table 1 


See Section 4 of [RFC4314] for conventions used in this table. 


Legend: 
SEUS The right is required 
DE Only one of the rights marked with * is required 


"Any": Atleast one of the "I", "r", "i", "K", "x", or "a" rights is required 
"Non": No rights required to perform the command 


Note that which permissions are needed in order to perform a GETQUOTAROOT command 
depends on the quota resource type being requested. For example, a quota on the number of 
messages (MESSAGE resource type) or total size of messages (STORAGE resource type) requires "r" 
right on the mailbox in question, since the quota involved would reveal information about the 
number (or total size) of messages in the mailbox. By comparison, the MAILBOX resource type 
doesn't require any right. 


7. Formal Syntax 


The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as 
specified in [ABNF]. 


Non-terminals referenced but not defined below are as defined by IMAP4 [RFC3501] [RFC9051]. 


Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or 
lowercase characters to define token strings is for editorial clarity only. Implementations MUST 
accept these strings in a case-insensitive fashion. 
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getquota = "GETQUOTA" SP quota-root-name 

getquotaroot = "GETQUOTAROOT" SP mailbox 

quota-list = "(" quota-resource *(SP quota-resource) ")" 
quota-resource = resource-name SP resource-usage SP resource-limit 
quota-response = "QUOTA" SP quota-root-name SP quota-list 
quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 
setquota = "SETQUOTA" SP quota-root-name SP setquota-list 
setquota-list = KO [setquota-resource *(SP setquota-resource)] 
setquota-resource = resource-name SP resource-limit 
quota-root-name = astring 

resource-limit = number64 

resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / 


"ANNOTATION-STORAGE" / resource-name-ext 


resource-name-ext = atom 
;; Future resource registrations 


resource-usage = number64 
;; must be less than corresponding resource-limit 


capability-quota = capa-quota-res / "QUOTASET" 
;; One or more capa-quota-res must be returned. 
;; Also "QUOTASET" can optionally be returned. 


capa-quota-res = "QUOTA=RES-" resource-name 


status-att =/ "DELETED" / "DELETED-STORAGE" 
;; DELETED status data item MUST be supported 
;; when the "QUOTA=RES-MESSAGE" capability is 
;; advertised. 
;; DELETED-STORAGE status data item MUST be 
;; supported when the "QUOTA=RES-STORAGE" 
;; capability is advertised. 


status-att-val =/ status-att-deleted / 
status-att-deleted-storage 


status-att-deleted = "DELETED" SP number 
DELETED status data item MUST be supported 
;; when the "QUOTA=RES-MESSAGE" capability is 
;; advertised. 


status-att-deleted-storage = "DELETED-STORAGE" SP number64 


;; DELETED-STORAGE status data item MUST be 
;; supported when the "QUOTA=RES-STORAGE" 
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;; capability is advertised. 
resp-text-code =/ "OVERQUOTA" 


number64 = <Defined in RFC 9051> 


8. Security Considerations 


Implementors should be careful to make sure the implementation of these commands does not 
violate the site's security policy. The resource usage of other users is likely to be considered 
confidential information and should not be divulged to unauthorized persons. In particular, no 
quota information should be disclosed to anonymous users. 


As for any resource shared across users (for example, a quota root attached to a set of shared 
mailboxes), a user that can consume or render unusable the resource can affect the resources 
available to the other users; this might occur, for example, by a user with permission to execute 
the SETQUOTA setting, which sets an artificially small value. 


Note that computing resource usage might incur a heavy load on the server. Server implementers 
should consider implementation techniques that lower the load on servers such as caching of 
resource usage information or usage of less precise computations when under heavy load. 


9. IANA Considerations 


9.1. Changes/Additions to the IMAP Capabilities Registry 


IMAP4 capabilities are registered by publishing a Standards Track or an IESG-approved 
Informational or Experimental RFC. The "IMAP Capabilities" registry is currently located at 
<https://www.iana.org/assignments/imap4-capabilities>. 


IANA has updated the reference for the QUOTA extension to point to this document. IANA has also 
added the "QUOTA=" prefix and the "QUOTASET" capability to the "IMAP Capabilities" registry with 
this document as the reference. 


IANA has added the following notes to the "IMAP Capabilities" registry: 


The prefix "QUOTA=RES-" is reserved per RFC 9208, Section 9.1. See Section 9.2 of that document for 
values that follow this prefix. 


All other capabilities starting with the "QUOTA=" prefix are reserved for future IETF Stream 
extensions to RFC 9208. 


9.2. IMAP Quota Resource Type Registry 


IANA has created a new registry for IMAP quota resource types. The registration policy for the 
"IMAP Quota Resource Types" registry is "Specification Required" [RFC8126]. 
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When registering a new quota resource type, the registrant needs to provide the following: 


e the name of the quota resource type 


e a short description 


e extra required IMAP commands/responses (if any) 


e extra optional IMAP commands/responses (if any) 


e name and email address of author 


e name and email address of change controller 


e a reference to a specification that describes the quota resource type in more detail 


Designated experts should check that the provided references are correct, the references describe 
the quota resource type being registered in sufficient detail to be implementable, the syntax of 
any optional commands/responses is correct (e.g., ABNF validates), and the syntax/description 
complies with rules and limitations imposed by IMAP [RFC3501] [RFC9051]. Designated experts 
should avoid registering multiple identical quota resource types under different names and 
should provide advice to requestors about other possible quota resource types to use. 


The initial contents of the "IMAP Quota Resource Types" registry are as follows: 


field name 


Name of the quota resource 
type: 


Description: 


Extra required IMAP 
commands/responses: 


Extra optional IMAP 
commands/responses: 


Author: 
Change Controller: 
Reference: 

Table 2: STORAGE 
field name 


Name of the quota resource 
type: 


Melnikov 


field value 


STORAGE 


The physical space estimate, in units of 1024 octets, of the 
mailboxes governed by the quota root. 


DELETED-STORAGE STATUS request data item and response 
data item 


N/A 


Alexey Melnikov <alexey.melnikov@isode.com> 
IESG <iesg@ietf.org> 
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field value 


MESSAGE 
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field name 


Description: 


Extra required IMAP 


commands/responses: 


Extra optional IMAP 


commands/responses: 


Author: 


Change Controller: 


IMAP QUOTA March 2022 


field value 


The number of messages stored within the mailboxes 
governed by the quota root. 


DELETED STATUS request data item and response data item 


N/A 


Alexey Melnikov <alexey.melnikov@isode.com> 


IESG <iesg@ietf.org> 


Reference: Section 5.2 of RFC 9208 
Table 3: MESSAGE 
field name field value 
Name of the quota resource type: MAILBOX 
Description: The number of mailboxes governed by the quota 
root. 
Extra required IMAP commands/ N/A 
responses: 
Extra optional IMAP commands/ N/A 
responses: 
Author: Alexey Melnikov <alexey.melnikov@isode.com> 


Change Controller: 
Reference: 

Table 4: MAILBOX 
field name 


Name of the quota 
resource type: 


Description: 


Melnikov 


IESG <iesg@ietf.org> 
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field value 


ANNOTATION-STORAGE 


The maximum size of all annotations [RFC5257], in units of 1024 
octets, associated with all messages in the mailboxes governed by 
the quota root. 
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field name field value 


Extra required IMAP N/A 
commands/ 
responses: 


Extra optional IMAP N/A 


commands/ 

responses: 

Author: Alexey Melnikov <alexey.melnikov@isode.com> 
Change Controller: IESG <iesg@ietf.org> 

Reference: Section 5.4 of RFC 9208 


Table 5: ANNOTATION-STORAGE 


10. Changes Since RFC 2087 


This document is a revision of [RFC2087], and it aims to clarify the meaning of different terms 
that were used in that RFC. It also provides more examples, gives guidance on allowed server 
behavior, defines an IANA registry for quota resource types, and provides initial registrations for 
4 of them. 


When compared with [RFC2087], this document defines two more commonly used resource types, 
adds an optional OVERQUOTA response code, and defines two extra STATUS data items 
("DELETED" and "DELETED-STORAGE’). The DELETED STATUS data item must be implemented if 
the "QUOTA=RES-MESSAGE" capability is advertised. The DELETED-STORAGE STATUS data item 
must be implemented if the "QUOTA=RES-STORAGE" capability is advertised. For extensibility, 
quota usage and quota limits are now 63-bit unsigned integers. 
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